Document History
Changes to this Specification are coordinated by IHO NIPWG. New editions will be made available via the IHO web site. Maintenance of the Specification shall conform to IHO Resolution 2/2007 (as amended).
Table — Document History
| Version Number | Date | Approved By | Purpose |
|---|---|---|---|
1.0.0 | April 2014? | S100WG? | Approved edition of S-411 |
1.1.0 | Nov 2024 | S100WG | Basic document structure in place |
1 Overview
1.2 References
[1] S-100 edition 5.2.0: IHO Universal Hydrographic Data Model, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-100/S-100_5.2.0_Final_Clean.pdf).
[2] S-44 edition 6.1.0: IHO Standards for Hydrographic Surveys, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-44/S-44_5E.pdf).
[3] S-49 edition 2.1.0: STANDARDIZATION of MARINERS’ ROUTEING GUIDES, International Hydrographic Organization (https://iho.int/uploads/user/pubs/standards/s-49/S-49_Ed.2.1.0_Standardization%20of%20Mariners%20Routeing%20Guides_EN.pdf).
[4] S-32 edition 1.0.0: Hydrographic Dictionary — Glossary of ECDIS Related Terms, International Hydrographic Organization (http://hd.iho.int/en/index.php/Main_Page).
[5] ISO 8601:2004: Data elements and interchange formats — Information interchange — Representation of dates and times, International Organization for Standardization (https://www.iso.org/standard/40874.html).
[6] ISO 639-2:1998: Codes for the representation of names of languages — Part 2: Alpha-3 code, International Organization for Standardization (https://www.iso.org/standard/4767.html).
[7] ISO 19103:2015: Geographic information — Conceptual schema language, International Organization for Standardization (https://www.iso.org/standard/56734.html).
[8] ISO 19111:2007: Geographic information — Spatial referencing by coordinates, International Organization for Standardization (https://www.iso.org/standard/41126.html).
[9] ISO 19115-1:2014/Amd 1:2018: Geographic information — Metadata — Part 1: Fundamentals — Amendment 1, International Organization for Standardization (https://www.iso.org/standard/73118.html).
[10] ISO 19115-2:2009: Geographic information — Metadata — Part 2: Extensions for imagery and gridded data, International Organization for Standardization (https://www.iso.org/standard/39229.html).
[11] ISO/TS 19115-3:2016: Geographic information — Metadata — Part 3: XML schema implementation for fundamental concepts, International Organization for Standardization (https://www.iso.org/standard/32579.html).
[12] ISO 19123:2005: Geographic information — Schema for coverage geometry and functions, International Organization for Standardization (https://www.iso.org/standard/40121.html).
[13] ISO/TS 19129:2009: Geographic information — Imagery, gridded and coverage data framework, International Organization for Standardization (https://www.iso.org/standard/43041.html).
[14] ISO 19131:2007/Amd 1:2011: Geographic information — Data product specifications — Amendment 1: Requirements relating to the inclusion of an application schema and feature catalogue and the treatment of coverages in an application schema., International Organization for Standardization (https://www.iso.org/standard/51790.html).
[15] ISO/IEC 19501:2005: Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2, International Organization for Standardization and International Electrotechnical Commission (https://www.iso.org/standard/32620.html).
[16] ISO 3166-2:2013: Codes for the representation of names of countries and their subdivisions — Part 2: Country subdivision code, International Organization for Standardization (https://www.iso.org/standard/63546.html).
[17] ISO/TS 19130:2010: Geographic information — Imagery sensor models for geopositioning, International Organization for Standardization (https://www.iso.org/standard/51789.html).
[18] ISO/TS 19130-2:2014: Geographic information — Imagery sensor models for geopositioning — Part 2: SAR, InSAR, lidar and sonar, International Organization for Standardization (https://www.iso.org/standard/56113.html).
[19] ISO/TS 19139-1:2019: Geographic information — XML schema implementation — Part 1: Encoding rules, International Organization for Standardization (https://www.iso.org/standard/67253.html).
[20] ISO/IEC 10646-1:2000: Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1: Architecture and Basic Multilingual Plane, International Organization for Standardization and International Electrotechnical Commission (https://www.iso.org/standard/29819.html).
1.3 Terms, definitions and abbreviations
1.3.1 Use of language
Within this document:
“Must” indicates a mandatory requirement.
“Should” indicates an optional requirement, that is the recommended process to be followed, but is not mandatory.
“May” means “allowed to” or “could possibly” and is not mandatory.
1.3.2 Terms and definitions
1.3.2.1 Accuracy
Closeness of agreement between a test result and the accepted reference values.
NOTE A test result can be from an observation or measurement.
1.3.2.2 Coordinate
One of a sequence of n numbers designating the position of a point in N-dimensional space.
NOTE The numbers must be qualified by units and CRS.
1.3.2.3 Coordinate Reference System
Coordinate system which is related to the real world by a datum.
1.3.2.4 Coverage
Feature that acts as a function to return values from its range for any direct position within its spatial, temporal, or spatiotemporal domain.
NOTE In other words, a coverage is a feature that has multiple values for each attribute type, where each direct position within the geometric representation of the feature has a single value for each attribute type.
EXAMPLE
Examples include a digital image, polygon overlay, or digital elevation matrix
1.3.2.5 Coverage Geometry
Configuration of the domain of a coverage described in terms of coordinates.
1.3.2.6 Direct Position
Position described by a single set of coordinates within a coordinate reference system.
1.3.2.7 Domain
Well-defined set.
NOTE Domains are used to define the domain set and range set of attributes, operators, and functions.
1.3.2.8 Depth
The vertical distance from a given water level to the bottom. In this standard, depth refers to the S-32 definition of “Depth Charted”.
NOTE The numbers must be qualified by units and datum.
1.3.2.9 Feature
Abstraction of real-world phenomena.
NOTE A feature may occur as a type or an instance. Feature type or feature instance should be used when only one is meant.
1.3.2.10 Feature Attribute
Characteristic of a feature.
NOTE A feature attribute type has a name, a data type, and a domain associated to it. A feature attribute instance has an attribute value taken from the value domain of the feature attribute type.
1.3.2.11 Function
Rule that associates each element from a domain (source, or domain of the function) to a unique element in another domain (target, co-domain, or range).
NOTE The range is defined by another domain.
1.3.2.12 Geometric Object
Spatial object representing a set of direct positions.
NOTE A geometric object consists of a geometric primitive, a collection of geometric primitives, or a geometric complex treated as a single entity. A geometric object may be the spatial characteristics of an object such as a feature or a significant part of a feature.
1.3.2.13 Grid
Network composed of two or more sets of curves in which the members of each set intersect the members of the other sets in a systematic way.
NOTE The curves partition a space into grid cells.
1.3.2.14 Grid Point
Point located at the intersection of two or more curves in a grid.
1.3.2.15 Lidar
An optical remote sensing technique that uses a laser pulse to determine distance.
NOTE Lidar may be used to determine depth in shallow water areas.
1.3.2.17 Range <coverage>
Set of values associated by a function with the elements of the spatiotemporal domain of a coverage.
1.3.2.18 Record
Finite, named collection of related items (objects or values).
NOTE Logically, a record is a set of pairs <name, item >.
1.3.2.19 Rectified Grid
Grid for which there is a linear relationship between the grid coordinates and the coordinates of an external coordinate reference system.
NOTE If the coordinate reference system is related to the earth by a datum, the grid is a georectified grid.
1.3.2.20 Referenceable Grid
Grid associated with a transformation that can be used to convert grid coordinate values to values of coordinates referenced to an external coordinate reference system.
1.3.2.21 Sonar
A technique that uses sound propagation through water to determine distance, primarily depth measurement.
1.3.2.22 Spatiotemporal Domain <coverage>
Domain composed of geometric objects described in terms of spatial and/or temporal coordinates.
NOTE The spatiotemporal domain of a continuous coverage consists of a set of direct positions defined in relation to a collection of geometric objects.
1.3.2.23 Surface
Connected 2-dimensional geometric primitive, representing the continuous image of a region of a plane.
NOTE The boundary of a surface is the set of oriented, closed curves that delineate the limits of the surface.
1.3.2.24 Uncertainty
The interval (about a given value) that will contain the true value of the measurement at a specific confidence level.
NOTE Errors exist and are the differences between the measured value and the true value. Since the true value is never known it follows that the error itself cannot be known. Uncertainty is a statistical assessment of the likely magnitude of this error. The numbers must be qualified by units.
In this document an S-102 uncertainty is always considered to be 1-dimensional and at the 2-sigma or 95% confidence level.
1.3.2.25 Vector
Quantity having direction as well as magnitude.
NOTE A directed line segment represents a vector if the length and direction of the line segment are equal to the magnitude and direction of the vector. The term vector data refers to data that represents the spatial configuration of features as a set of directed line segments.
1.3.3 Abbreviated terms
This Product Specification adopts the following convention for presentation purposes:
CRS
Coordinate Reference System
DCEG
Data Classification and Encoding Guide
ECDIS
Electronic Chart Display Information System
ENC
Electronic Navigational Chart
EPSG
European Petroleum Survey Group
HDF
Hierarchical Data Format
HSSC
IHO Hydrographic Services and Standards Committee (formerly CHRIS)
IEC
International Electrotechnical Commission
IHO
International Hydrographic Organization
IMO
International Maritime Organization
IOGP
International association of Oil and Gas Producers (formerly OGP)
ISO
International Organization for Standardization
MRN
Maritime Resource Name
S-100 WG
S-100 Working Group
S-102 PT
S-102 Project Team
TS
Technical Specification
TSMAD
Transfer Standard Maintenance and Application Development Working Group
UML
Universal Modelling Language
URI
Uniform Resource Identifier
XML
eXtensible Markup Language
1.4 General S-102 data product description
- Title
Marine Protected Area Product Specification.
- Abstract
A Marine Protected Area (MPA) is a protected area whose boundaries include an area of the ocean. They include areas of the intertidal or sub-tidal terrain, together with their overlying water and associated flora, fauna, historical and cultural features, which have been reserved by law or other effective means to protect part or all of, the enclosed environment. For example, MPAs may be established to protect fish species, rare habitat area, or entire ecosystems. MPAs can range from, simple declarations to protect a resource, to areas that are extensively regulated. The degree to which environmental regulations affect shipping varies according to whether MPAs are located in territorial waters, exclusive economic zones, or high seas. These limits are regulated by the law of the sea. Most MPAs are located in the territorial waters of coastal states, where enforcement can be ensured. MPAs can also however be established in a state’s exclusive economic zone and even within international waters. For example in 1999, Italy, France and Monaco jointly established a cetacean sanctuary in the Ligurian Sea named the Pelagos Sanctuary for Mediterranean Marine Ma
- Acronym
S-122
- Content
Datasets conforming to this specification will contain all relevant MPA information for the area of coverage. Additionally there will be relevant metadata data quality, production authority, data sources and publication date.The DCEG provides guidance on how data product content must be captured. Annex A, in addition to [tsf], will provide implementation guidance for developers.
- Spatial Extent
Description: Global coverage of maritime areas.
East Bounding Longitude: 180°
West Bounding Longitude: -180°
North Bounding Latitude: 90°
South Bounding Latitude: -90°- Purpose
Describing marine protected area information in the maritime domain for utilization in ECDIS, and to allow the producer to exchange marine protected area information with interested stakeholders.
1.5 Product Specification metadata
This information uniquely identifies this Product Specification and provides information about its creation and maintenance. For further information on dataset metadata, see Section 12.
- Title
Marine Protected Area Product Specification
- S-100 Version
5.2.0
- S-122 Version
1.2.1
- Date
November 2024
- Language
English
- Classification
Unclassified
- Contact
International Hydrographic Bureau
4 Quai Antoine 1er
B.P. 445
MC 98011 MONACO CEDEX
Telephone: +377 93 10 81 00
Fax: +377 93 10 81 40
Email: info@iho.int- URL
- Identifier
S-122
- Maintenance
Changes to the Product Specification S-122 are coordinated by the IHO NIPWG, and must be made available via the IHO web site. Maintenance of the Product Specification must conform to IHO Resolution 2/2007, as amended.
1.6 IHO Product Specification Maintenance
1.6.1 Introduction
Changes to S-122 will be released by the IHO as a New Edition, revision, or clarification.
1.6.2 New Edition
New Editions of S-122 introduce significant changes. New Editions enable new concepts, such as the ability to support new functions or applications, or the introduction of new constructs or data types. New Editions are likely to have a significant impact on either existing users or future users of S-122. All cumulative revisions and clarifications must be included with the release of approved New Editions.
1.6.3 Revision
Revisions are defined as substantive semantic changes to S-122. Typically, revisions will change S-122 to correct factual errors; introduce necessary changes that have become evident as a result of practical experience or changing circumstances. A revision must not be classified as a clarification. Revisions could have an impact on either existing users or future users of S-122. All cumulative clarifications must be included with the release of approved revisions.
Changes in a revision are minor and ensure backward compatibility with the previous versions within the same Edition. Newer revisions, for example, introduce new features and attributes. Within the same Edition, a dataset of one version could always be processed with a later version of the Feature and Portrayal Catalogues.
In most cases a new feature or portrayal catalogue will result in a revision of S-122.
1.6.4 Clarification
Clarifications are non-substantive changes to S-122. Typically, clarifications: remove ambiguity; correct grammatical and spelling errors; amend or update cross references; insert improved graphics in spelling, punctuation and grammar. A clarification must not cause any substantive semantic change to S-122.
Changes in a clarification are minor and ensure backward compatibility with the previous versions within the same Edition. Within the same Edition, a dataset of one clarification version could always be processed with a later version of the Feature and Portrayal Catalogues, and a Portrayal Catalogue can always rely on earlier versions of the Feature Catalogue.
1.6.5 Version Numbers
The associated version control numbering to identify changes (n) to S-122 must be as follows:
New Editions denoted as n.0.0
Revisions denoted as n.n.0
Clarifications denoted as n.n.n
2 Specification Scope
This product specification defines only one general scope which applies to all its sections.
- Scope Identification
GeneralScope
3 Data Product Identification
- Title
Marine Protected Areas
- Alternate Title
None
- Abstract
- Topic Category
Main topics for the product, as according to ISO 19115-1:2014/Amd 1:2018 MD_TopicCategoryCode:
006 — elevation
014 — oceans
012 — inlandWaters
- Geographic Description
Areas specific to marine navigation.
- Spatial Resolution
…
- Purpose
…n.
- Language
English (Mandatory), other (Optional)
- Classification
Data can be classified as one of the following:
Unclassified;
Restricted;
Confidential;
Secret;
Top Secret;
Sensitive but unclassified;
For official use only;
Protected;
Limited distribution
- Spatial Representation Type
Type of spatial representation for the product, as defined by the ISO 19115-1:2014/Amd 1:2018 MD_SpatialRepresentationTypeCode: XXX — XXX.
- Point of Contact
Producing Agency
4 Data Content and Structure
4.1 Introduction
intro here.
5 Coordinate Reference Systems (CRS)
5.1 Introduction
The Coordinate Reference System information contained in [tab-s102-coordinate-reference-systems-epsg-codes] is defined in the manner specified in S-100, Part 6. The vertical datum is specified separately using other root group attributes.
5.2 Horizontal Coordinate Reference System
Table 5-1 — S-4111 Coordinate Reference Systems (EPSG Codes)
| EPSG Code | Coordinate Reference System |
|---|---|
| 4326 | WGS84 |
| 32601 — 32660 | WGS 84 / UTM Zone 1N to Zone 60N |
| 32701 — 32760 | WGS 84 / UTM Zone 1S to Zone 60S |
| 5041 | WGS 84 / UPS North (E,N) |
| 5042 | WGS 84 / UPS South (E,N) |
| The full reference to EPSG can be found at https://epsg.org. | |
- Horizontal Coordinate Reference System
EPSG (see [tab-s102-coordinate-reference-systems-epsg-codes])
- Projection
NONE/UTM/UPS
- Temporal reference system
Gregorian Calendar
- Coordinate Reference System registry
- Date type (according to ISO 19115-1:2014/Amd 1:2018)
002 — publication
- Responsible party
International Association of Oil & Gas Producers (IOGP)
- URL
5.3 Vertical Coordinate Reference System
Although in this product there are no direct vertical coordinates the values of the depth attributes are indirectly such coordinates. Therefore, it is important to specify the vertical CRS to which these values conform. The vertical CRS is an earth gravity-based, one-axis coordinate system. The Orientation of the axis is defined by the vertical coordinate system attribute (verticalCS) in the root group (see Table 10-2).
The vertical datum must be taken from the code-list specified by the IHO Geospatial Information (GI) Registry for the attribute named Vertical Datum. It will be defined in the root group as an HDF5 attribute (see Table 10-2).
5.4 Temporal reference system
The temporal reference system is the Gregorian calendar for date and UTC for time. Time is measured by reference to Calendar dates and Clock time in accordance with ISO 8601:2004, Clause 5.4.4. A date-time variable will have the following 16-character format: yyyymmddThhmmssZ.
6 Data Quality
Data quality allows users and user systems to assess fitness for use of the provided data. Data quality measures and the associated evaluation are reported as metadata of a data product. This metadata improves interoperability with other data products and provides usage by user groups that the data product was not originally intended for. The secondary users can make assessments of the data product usefulness in their application based on the reported data quality measures.
6.1 Completeness
6.1.1 Commission
Commission is applicable for S-102. Data Producers must verify that no excess items have been included in the dataset. Such excess items include duplicate items, which must be removed.
If no excess items are present, the dataset PASSES this test.
6.1.2 Omission
Omission is applicable for S-102. Data Producers must verify that no items that should have been included in the dataset have been omitted.
If no necessary items have been omitted, the dataset PASSES this test.
6.2 Logical consistency
6.2.1 Conceptual consistency
Conceptual Consistency is applicable for S-411 and follows the guidelines from S-100, Part 1.
Data Producers must verify that the dataset conforms to the S-100 General Feature Model.
If the dataset conforms to the S-100 General Feature Model, the dataset PASSES this test.
6.2.2 Domain consistency
Domain consistency is applicable for S-411 and follows the guidelines from S-100, Part 5.
Data Producers must verify that the dataset conforms to the S-102 Feature Catalogue and to Annex A.
If the dataset conforms to the S-411 Feature Catalogue and to Annex A, the dataset PASSES this test.
6.2.3 Format consistency
Format Consistency is applicable for S-411 and follows the guidelines from S-100, Part 10c.
Data Producers must verify that the dataset conforms to Section 10 of this Product Specification.
If the dataset conforms to Section 10, the dataset PASSES this test.
6.5 Thematic accuracy
6.5.3 Quantitative attribute accuracy
As defined in S-100, Part 4c the data quality for the depth coverage is also defined as a co-located optional coverage, which is the uncertainty. This value particularly refers to the vertical uncertainty at each grid point. The uncertainty coverage supports multiple definitions of vertical uncertainty.
See Table 10-9.
7 Data Capture and Classification
The DCEG describes how data describing the real world should be captured using the types defined in the S-102 Feature Catalogue. The DCEG is located at Annex A.
A number of sounding techniques are used to capture bathymetric data. It is permitted, but not required, to include data acquisition information in the metadata of an S-102 Bathymetric Surface product. The metadata class S102_AcquisitionMetadata has been defined, but the information elements to populate this metadata class should be identified in a national profile of S-102.
7.1 Quality and source metadata
Quality and source metadata in S-102 are intended to enable and support future navigation software to appropriately auto-generate and attribute cartographic features such as custom depth contours and soundings from S-102 products, all while minimally impacting the overall file size of the product.
Quality and source metadata are encoded in a feature attribute table compliant with both HDF5 and S-100. This feature attribute table will provide valuable information about the bathymetry on a grid cellwise basis compared to traditional vector-based metadata files, simplifying the interpretation and implementation by navigation software systems.
The fields of the feature attribute table are defined elsewhere in this Product Specification (Table 10-7).
Quality and source metadata in S-102 are based on S-101 quality attributes, with significant augmentations and omissions described below. The quality and source metadata support a threefold purpose:
Support S-101-defined attribution of auto-generated vector depth areas, depth contours, and soundings created directly from the S-102 dataset.
The attribute featureSizeVar is meant to augment featureSize which corresponds to S-101 size of features detected. As noted in S-101, size of features detected is intended to be described as the smallest size in cubic metres the survey was capable of detecting. Depending on various survey parameters, this definition might require different depth ranges to have different values. For example, a survey vessel working at a fixed height off the seafloor (such as an autonomous underwater survey vessel) could maintain a fixed feature detection size capability over a wide range of depths. Conversely, a surface vessel working over that same range of depths may have a feature detection capability that varies with depth. The latter situation could foreseeably cause the detection capability to be ambiguous and potentially misrepresented. For this reason, featureSizeVar is defined as the ratio (expressed as a percentage) of minimum detectable feature size to water depth. When both featureSize and featureSizeVar are present, the whichever value implies a larger feature size should be considered valid. The expectation is that featureSizeVar will be set to zero if the feature size does not scale with depth. As with featureSize, featureSizeVar should be ignored if significantFeatures is False.
Note that depth range maximum and minimum in S-101 are omitted. The assumption is that if this information is required, then the corresponding grid cells in the elevation layer can be queried for a minimum and maximum depth for each table row.
Provide necessary uncertainty information as an input into critical underkeel clearance precision navigation systems.
Prevent the automated selection of soundings from interpolated grid cells, while still providing the continuous data required for depth contour creation. This purpose is accomplished by the bathyCoverage Boolean attribute field. This field enables the flagging of grid cells populated by interpolation (when that interpolation occurs across gaps in bathymetric observations greater than the S-102 grid spatial resolution). This functionality is especially useful in side-scan surveys which are characterized by gaps in bathymetric observations with full coverage side-scan imagery. In this case, interpolated gaps between bathymetry coverage would show fullSeafloorCoverageAchieved = True and bathyCoverage = False. However, if fullSeafloorCoverageAchieved = False, bathyCoverage must also equal False (e.g., gaps between single beam echosounder data without correlating side scan sonar coverage). Thus, this facility will provide navigation software systems with the required information necessary to preferably select soundings from direct bathymetric observations.
Quality and source metadata are encoded as records within a featureAttributeTable dataset, which is itself within the QualityOfBathymetryCoverage container group (Table 10-7).
8 Data Maintenance
8.1 Maintenance and update frequency
Datasets are maintained by replacement on a dataset basis. That is, the entire data product and the associated metadata are replaced as a unit. This is unlike vector data that may be updated incrementally. Also, each replacement data set must have its own digital signature.
8.2 Data source
Data producers must use applicable sources to maintain and update data and provide a brief description of the sources that were used to produce the dataset.
8.3 Production process
Data Producers should follow their established production processes for maintaining and updating datasets.
10 Data Product Format (Encoding)
10.1 Introduction
The S-102 data set must be encoded using the Hierarchical Data Format standard, Version 5 (HDF5).
- Format Name
HDF5
- Version
1.8.8
- Character Set
UTF-8
- Specification
The key idea behind the S-102 product structure is that each coverage is a feature. Each of these features is co-located with the others. Therefore, they share the same spatial metadata, and each is required to correctly interpret the others.
For the use of HDF5, the following key concepts (S-100, Part 10c, Clause 5.1) are important:
- File
a contiguous string of bytes in a computer store (memory, disk, etc.), and the bytes represent zero or more objects of the model;
- Group
a collection of objects (including groups);
- Dataset
a multidimensional array of data elements with attributes and other metadata;
- Dataspace
a description of the dimensions of a multidimensional array;
- Datatype
a description of a specific class of data element including its storage layout as a pattern of bits; (Enumerations are encoded with unsigned 8-bit or unsigned 16-bit indices, depending on the number of transported values.)
- Attribute
a named data value associated with a group, dataset, or named datatype and stored as a scalar;
- Property List
a collection of parameters (some permanent and some transient) controlling options in the library.
In addition, datasets may be a compound (a single record consisting of an array of simple value types) and have multiple dimensions.
10.2 Product structure
The structure of the data product follows the form given in S-100, Part 10c — HDF5 Data Model and File Format. The general structure, which was designed for several S-100 products is given in Figure 10-1.
Figure 10-1 — Outline of the generic data file structure
Figure 10-1 shows the four levels defined within the HDF encoding as defined in S-100, Part 10c. Below is a further definition of these levels.
- Level 1
At the top level lies the Root Group, and it contains the Root Metadata and two subsidiary groups. The Root Metadata applies to all S-100 type products.
- Level 2
The next Level contains the Feature Information Group and the Feature Container Group. The Feature Information Group contains the feature BathymetryCoverage, the feature attribute codes and the optional feature QualityOfBathymetryCoverage. The Feature Container Group contains the Feature Metadata and one or more Feature Instance Groups.
- Level 3
This level contains one or more Feature Instance groups. A BathymetryCoverage feature instance is a bathymetric gridded data set for a single region and at a single vertical datum. A QualityOfBathymetryCoverage feature instance is a corresponding dataset for the same single region and for all applicable vertical datums.
- Level 4
This level contains the actual data for each feature. In S-102 BathymetryCoverage and QualityOfBathymetryCoverage each use the ValuesGroup to define the content. The other groups at this level are not used.
In Table 10-1 below, levels refer to HDF5 structuring (see Figure 10-1). Naming in each box below the header line is as follows: Generic name; S-100 or S-102 name, or nothing if none; and (HDF5 type) group, attribute or attribute list, or dataset. Figure 10-2 depicts the same structure using a graphical representation.
Table 10-1 — Overview of S-102 Data Product
| LEVEL 1 CONTENT | LEVEL 2 CONTENT | LEVEL 3 CONTENT | LEVEL 4 CONTENT |
|---|---|---|---|
General Metadata | |||
Feature Codes | Feature Name | ||
QualityOfBathymetryCoverage | |||
Feature Codes | |||
Feature Type | Type Metadata | ||
Feature Instance | Instance Metadata | ||
First data group | Group Metadata | ||
X and Y Axis Names | Bathymetric Data Array values | ||
Feature Type | Metadata | ||
QualityOfBathymetryCoverage.01 | Group_001 | Group Metadata | |
X and Y Axis Names | Quality of Bathymetry Data Array | ||
Feature Attribute Table |
Figure 10-2 — Hierarchy of S-102 Data Product
The following sections explain entries in Table 10-1 in greater detail.
10.2.1 Root Group
The root group is required by HDF5. The S-100 HDF5 format (S-100, Part 10c) attaches metadata attributes applicable to the whole dataset to this group. S-102 uses all the S-100 attributes except geographicIdentifier and metaFeatures. The attributes used in S-102 are listed in Table 10-2, with specific requirements, if any, added in the Remarks column.
Table 10-2 — Root group attributes
| No | Name | Camel Case | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
1 | Product specification number and version | productSpecification | 1 | String | S-100, Part 10c, Table 6 |
2 | Time of data product issue | issueTime | 0..1 | String (Time format) | |
3 | Issue date | issueDate | 1 | String (Date format) | |
4 | Horizontal CRS | horizontalCRS | 1 | Integer | The identifier (EPSG code) of the horizontal CRS as defined in Clause 5.2 (see Clause 10.2.1, Note 2). |
5 | Epoch of realization | epoch | 0..1 | String | |
6a | Bounding box | westBoundLongitude | 1 | Float | The values are in decimal degrees. The root bounding box needs to encompass all data, including fill values. The outermost cell boundaries of the grid cells and the bounding box / domain extent polygon of each feature instance group form the basis for the root bounding box. |
6b | eastBoundLongitude | 1 | Float | ||
6c | southBoundLatitude | 1 | Float | ||
6d | northBoundLatitude | 1 | Float | ||
7 | Metadata | metadata | 0..1 | String | Name of metadata file |
8 | Vertical coordinate system | verticalCS | 1 | Integer | Mandatory in S-102. The only allowed value is: |
9 | Vertical coordinate base | verticalCoordinateBase | 1 | Enumeration | Mandatory in S-102. |
10 | Vertical datum reference | verticalDatumReference | 1 | Enumeration | Mandatory in S-102. |
11 | Vertical datum | verticalDatum | 1 | Integer | Numeric code from IHO GI Registry |
NOTE 1 The productIdentifier (“S-102”) and version fields (X.X.X) of S100_ProductSpecification must be used. NOTE 2 The value horizontalCRS specifies the horizontal Coordinate Reference System. At the time of writing, S-100 does not yet provide a mechanism for this value’s definition within HDF5 encoding (such as an enumeration of horizontal CRSs). Consequently, this configuration causes a deviation from S-100. The horizontal datum is implicitly defined by this CRS because each horizontal CRS consists of a coordinate system and a datum. S-102 does not use “user defined” CRS as mentioned in S-100, Part 10c, Table 6. NOTE 3 The baseCRS is the geodetic CRS on which the projected CRS is based. In particular, the datum of the base CRS is also used for the derived CRS (see S-100, Part 6, Table 6). NOTE 4 This is the default vertical datum. If and only if a BathymetryCoverage feature instance group does not specify a vertical datum, this (Root Group) vertical datum shall apply. | |||||
10.2.2 Feature Codes (Group_F)
No attributes.
This group specifies the S-100 features to which the data applies, and consists of three components:
featureCode — a 1-dimensional dataset with the featureCode(s) of the S-100 feature(s) contained in the data product. For S-102, the dataset has only two elements — the string “BathymetryCoverage” and “QualityOfBathymetryCoverage” (without quotes). The entries in this dataset give the names of the other two components of Group_F.
BathymetryCoverage — A 1-dimensional dataset that contains the standard definition of the bathymetry coverage feature class in terms of its attributes and their types, units of measure, etc. The datatype of its elements is the compound type described in S-100, Part 10c, Table 8.
QualityOfBathymetryCoverage — A 1-dimensional dataset of the same datatype as the BathymetryCoverage dataset described above. This QualityOfBathymetryCoverage dataset contains the definition of the reference to metadata records. The reference is a single integer which identifies a metadata record in featureAttributeTable (described in S-100, Part 10c, Clause 9.6.2 and Clause 10.2.8.
10.2.3 BathymetryCoverage and QualityOfBathymetryCoverage Tables (in Group_F)
BathymetryCoverage and QualityOfBathymetryCoverage are arrays of compound type elements, whose components are the 8 components specified in Table 10-3.
Table 10-3 — Sample contents of the BathymetryCoverage and QualityOfBathymetryCoverage arrays
| Name | Explanation | BathymetryCoverage | QualityOfBathymetryCoverage | |
|---|---|---|---|---|
S-100 Attribute 1 | S-100 Attribute 2 | S-100 Attribute 1 | ||
code | Camel Case code of attribute as in Feature Catalogue | depth | uncertainty | iD |
name | Long name as in Feature Catalogue | depth | uncertainty | ID |
uom.name | Units (uom.name from S-100 Feature Catalogue) | metres | metres | (empty) |
fillValue | Fill value (integer or float, string representation, for missing values) | 1000000 | 1000000 | 0 |
datatype | HDF5 datatype, as returned by H5Tget_class() function | H5T_FLOAT | H5T_FLOAT | H5T_INTEGER |
lower | Lower bound on value of attribute | -14 | 0 | 1 |
upper | Upper bound on value of attribute | 11050 | (empty) | (empty) |
closure | Open or Closed data interval. See S100_IntervalType in S-100, Part 1. | closedInterval | geSemiInterval | geSemiInterval |
NOTE The uncertainty attribute of BathymetryCoverage may be omitted under certain conditions. See Clause 10.2.7. | ||||
According to S-100, Part 10c, Clause 9.5, “All the numeric values in the feature description dataset are string representations of numeric values; for example, “-9999.0” not the float value -9999.0.”
While the sample contents are shown in the two attributes columns, these are actually rows in the BathymetryCoverage table. They are also each a single HDF5 compound type and represent a single HDF5 element in the table.
All cells shall be HDF5 variable length strings. The minimum and maximum values are stored in lower and upper columns. Variable length strings allow future proofing the format in the event editing is allowed or correcting these values is required.
10.2.4 Root BathymetryCoverage
Table 10-4 — Attributes of BathymetryCoverage feature container group
| No | Name | Camel Case | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
| 1 | Data organization index | dataCodingFormat | 1 | Enumeration | Value: 2 |
| 2 | Dimension | dimension | 1 | Integer unsigned 8-bit | Value: 2 |
| 3 | Common point rule | commonPointRule | 1 | Enumeration | Value: 2 (low) see S-100, Part 8, Table 11. |
| 4 | Horizontal position uncertainty | horizontalPositionUncertainty | 1 | Float 32-bit | Value: -1.0 (if unknown or not available) |
| 5 | Vertical position uncertainty | verticalUncertainty | 1 | Float 32-bit | Value: -1.0 (if unknown or not available) |
| 6 | Number of feature instances | numInstances | 1 | Integer unsigned 8-bit | This is the total number of Feature Instance Groups within the Feature Container Group. The minimum is 1. see Clause 10.2.4, Note |
| 7a | Sequencing rule | sequencingRule.type | 1 | Enumeration | Value: 1 (linear) see S-100, Part 8, Table 12. |
| 7b | sequencingRule.scanDirection | 1 | String | Value: <axisNames entry> (comma-separated). For example, “latitude,longitude”. Reverse scan direction along an axis is indicated by prefixing a ‘-’ sign to the axis name. See [scanDirection] | |
| 8 | Interpolation type | interpolationType | 1 | Enumeration | Value: 1 (nearestneighbor). See S-100, Part 8, Table 13 |
| 9 | Offset of data point in cell | dataOffsetCode | 1 | Enumeration | Value: 5 barycenter (centroid) of cell. See S-100, Part 10c, Table 10 |
NOTE The number depends on the number of different vertical datums in the Feature Container Group. | |||||
10.2.5 Feature Instance group — BathymetryCoverage.nn
The BathymetryCoverage Feature Container Group can contain one or more Feature Instance Groups. The naming of the Feature Instance Groups follows the notation specified by the S-100. For generalization, the numbering is indicated with “.nn”.
Each feature instance group implements a unique vertical datum. All feature instance groups must share the same spatial location and extent. For each feature instance group, only the grid cells falling within the area of validity for that feature instance group’s vertical datum should be populated with (real) data. Within that feature instance group, all other grid cells should be populated with the fill value. Therefore, it is expected that:
The only grid cells that should be populated in more than one feature instance group are those that fall along a vertical datum boundary.
Where multiple population occurs, the ECDIS should choose the set of values resulting in the most conservative description to the mariner. (I.e., it should choose the shoalest adjusted depth.)
As derived from S-100, Part 10c, Clause 9.7 and S-100, Part 10c, Table 12, Table 10-5 and Table 10-6 describe the structure and attributes, respectively, of the BathymetryCoverage feature instance group.
Table 10-5 — Structure of BathymetryCoverage feature instance group
| Group | HDF5 Category | Name | Mult | Data Type | Remarks / Data Space |
|---|---|---|---|---|---|
| /BathymetryCoverage/ BathymetryCoverage.01 | attributes | (see Remarks) | 1 | (see Remarks) | Single-valued attributes as descripted in Table 10-6 |
| Dataset | domainExtent.polygon | 0..1 | Compound (Float, Float) | Spatial extent of the domain of the coverage Array (1-d): i=0, P Components: Either this or the bounding box attribute must be populated. | |
| /BathymetryCoverage/ BathymetryCoverage.nn | attributes | (see Remarks) | 1 | (see Remarks) | Single-valued attributes as descripted in Table 10-6 |
| Dataset | domainExtent.polygon | 0..1 | Compound (Float, Float) | Spatial extent of the domain of the coverage Array (1-d): i=0, P Components: Either this or the bounding box attribute must be populated. |
Table 10-6 — Attributes of BathymetryCoverage feature instance group
| No | Name | Camel Case | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
| 1a | Bounding box | westBoundLongitude | 0..1 | Float 32-bit | Coordinates should refer to the previously defined Coordinate Reference System. Either this or the domainExtent.polygon dataset must be populated |
| 1b | eastBoundLongitude | 0..1 | Float 32-bit | ||
| 1c | southBoundLatitude | 0..1 | Float 32-bit | ||
| 1d | northBoundLatitude | 0..1 | Float 32-bit | ||
| 2 | Number of groups | numGRP | 1 | Integer unsigned 8-bit | The number of data values groups contained in this instance group. Value: 1 |
| 3 | Longitude of grid origin | gridOriginLongitude | 1 | Float 64-bit | Longitude or easting of grid origin. Unit: (to correspond with previously defined Coordinate Reference System) |
| 4 | Latitude of grid origin | gridOriginLatitude | 1 | Float 64-bit | Latitude or northing of grid origin. Unit: (to correspond with previously defined Coordinate Reference System) |
| 5 | Grid spacing, longitude | gridSpacingLongitudinal | 1 | Float 64-bit | Cell size in x dimension. |
| 6 | Grid spacing, latitude | gridSpacingLatitudinal | 1 | Float 64-bit | Cell size in y dimension. |
| 7 | Number of points, longitude | numPointsLongitudinal | 1 | Integer unsigned 32-bit | Number of points in x dimension. |
| 8 | Number of points, latitude | numPointsLatitudinal | 1 | Integer unsigned 32-bit | Number of points in y dimension. |
| 9 | Start sequence | startSequence | 1 | String | Grid coordinates of the grid point to which the first in the sequence of values is to be assigned. The choice of a valid point for the start sequence is determined by the sequencing rule. Format: n, n Example: “0,0” (without quotes) |
| 10 | Vertical datum | verticalDatum | 0..1 | Integer unsigned 16-bit | see remark Table 10-2 row vertical datum and [mvdvdr] Mandatory for feature instance groups with a different vertical datum from that specified in the Root Group (prohibited otherwise) |
| 11 | Vertical datum reference | verticalDatumReference | 0..1 | Integer unsigned 8-bit | The only allowed value is 1: s100VerticalDatum (see S-100, Part 10c, Table 23). see [mvdvdr] Mandatory if this value were to differ from what is contained in the Root Group |
The gridOriginLongitude, gridOriginLatitude, gridSpacingLongitudinal, and gridSpacingLatitudinal attributes should be in the same geographic units as the bounding box. Note that this practice deviates from S-100 where it indicates that this value should be in Arc Degrees.
numPointsLongitude and numPointsLatitude must contain the number of cells in the x and y dimensions of the values table.
The S-102 uses the “Overriding of Attributes” concept of the S-100, Part 10c, Clause 9.7.1. This usage allows the feature instance group to overwrite the attributes of a higher group, in this case the verticalDatum. The default vertical datum is specified in the root group (see Table 10-2). The feature instance group for this default vertical datum must not use the additional attributes verticalDatum and verticalDatumReference (on the feature instance group).
If multiple vertical datums are present in the product, a separate feature instance group must be created for each vertical datum. These feature instance groups must use the additional attribute verticalDatum (on the feature instance group).
Note: At present, this Product Specification does not allow values other than 1: s100VerticalDatum for verticalDatumReference. However, if future changes allow the value of 2: EPSG (and if the value at the feature instance group differs from what is contained in the Root Group), then this value would become mandatory.
According to S-100, either the BoundingBox at the Feature Instance Group or the domainExtent.polygon must be specified. If domainExtent.polygon is specified, the BoundingBox is not specified in this case. The grid cells that do not belong to the area of the respective vertical datum should be assigned the fill value. If more than one domainExtent.polygon is used, those of different feature instance groups should not overlap. At positions where the polygons of different Feature Instance groups touch, the edges should be identical. The domainExtent.polygon does not have to follow grid cell boundaries but is an independent vector geometry based on the SoundingDatum surface from S-101. The domainExtent.polygon only supports a simple polygon geometry in accordance with S-100, Part 10c, Table 11. The mapping of multi-polygons and inner rings is not possible.
10.2.6 The values group — Group_001
This group contains 5 attributes, all of which are mandatory. According to S-100, Part 10c, Table 19, timePoint applies because the dataCodingFormat = 2. The other four attributes for this group are an extension of this Product Specification and, thus, are not defined by S-100, Part 10c. Table 10-7 lists all 5 attributes.
Table 10-7 — Attributes of values group
| No | Name | Camel Case | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
| 1 | minimum Depth | minimumDepth | 1 | Float 32-bit | The minimum depth value in the values dataset(s) of this group |
| 2 | maximum Depth | maximumDepth | 1 | Float 32-bit | The maximum depth value in the values dataset(s) of this group |
| 3 | minimum Uncertainty | minimumUncertainty | 1 | Float 32-bit | The minimum uncertainty value in the values dataset(s) of this group. If no uncertainty values are in the dataset(s) the value must be the fillValue |
| 4 | maximum Uncertainty | maximumUncertainty | 1 | Float 32-bit | The maximum uncertainty value in the values dataset(s) of this group. If no uncertainty values are in the dataset(s) the value must be the fillValue |
| 5 | Time stamp | timePoint | 1 | String | Because S-102 specifies survey dates elsewhere in its structure, this value should always be the fill value: 00010101T000000Z |
The group contains an HDF5 dataset named values containing the bathymetric gridded data.
10.2.7 BathymetryCoverage feature instance group — values dataset
This dataset contains the compound data arrays containing bathymetric gridded data. These components are explained below.
For bathymetric gridded data, the dataset includes a two-dimensional array containing always the depth and under certain conditions uncertainty data. These dimensions are defined by numPointsLongitudinal and numPointsLatitudinal. By knowing the grid origin and the grid spacing, the position of every grid point and grid cell can be simply computed.
If the uncertainty for each grid cell is equal, it is not necessary to store it at each cell in the grid. The uniqueness of the uncertainty results from the equality of the attributes minimumUncertainty and maximumUncertainty of Group_001 of the BathymetryCoverage (see Table 10-7 No. 3 & 4). If the uncertainty values at the grid cells are omitted, it must be ensured that the entry of the uncertainty of the BathymetryCoverage in the Group_F is also omitted (see Table 10-3). This type of storage technique can reduce the amount of memory required for the uncertainty without loss of information. The uncertainty of each grid cell can be immediately obtained from the minimumUncertainty or maximumUncertainty attributes of Group_001 of the BathymetryCoverage.
If the uncertainty is not the same for each grid cell, it must be stored at each cell in the grid. For unknown or unused uncertainty data, it must be filled with the fillValue specified in the Group_F feature information dataset.
The grid cell values are stored in two-dimensional arrays with a prescribed number of columns (numCOL) and rows (numROW). This grid is defined as a regular grid (dataCodingFormat = 2); therefore, the depth and uncertainty values will be for each cell in the grid. The data type of the array values is a compound with one or two members.
10.2.8 Root QualityOfBathymetryCoverage
The QualityOfBathymetryCoverage container group has the same metadata attributes as BathymetryCoverage container group (see Table 10-4). The values of the attributes must also be the same as the BathymetryCoverage container group. An exception is the attribute dataCodingFormat, which must be ‘9’. The use of multiple BathymetryCoverage Feature Instance groups (different Vertical Datums) does not affect the multiplicity of the QualityOfBathymetryCoverage, which remains 0 to 1. This means that the different BathymetryCoverage Feature Instance groups share a common QualityOfBathymetryCoverage.
The QualityOfBathymetryCoverage container group contains an additional 1-dimensional array named featureAttributeTable (S-100, Part 10c, Table 9; S-100, Part 10c, Clause 9.6.2). This dataset is mandatory within the QualityOfBathymetryCoverage group. Each element of this array is a metadata record of HDF5 compound type. The fields are described in Table 10-8 below.
Table 10-8 — Elements of featureAttributeTable compound datatype
| No | Attribute | Description | Mult | Data Type | Remarks |
|---|---|---|---|---|---|
| 1 | id | Metadata record identifier | 1 | Integer unsigned 32-bit | Each record must have a unique identifier. |
| 2 | dataAssessment | The categorization of the assessment level of bathymetric data for an area. | 0..1 | Integer unsigned 8-bit | *1: Assessed *2: Unassessed *3: Oceanic |
| 3 | featuresDetected.leastDepthOfDetectedFeaturesMeasured | Expression stating if the least depth of detected features in an area was measured. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 10.2.8, Note 1. |
| 4 | featuresDetected.significantFeaturesDetected | A statement expressing if significant features have or have not been detected in the course of a survey. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 10.2.8, Note 2. |
| 5 | featuresDetected.sizeOfFeaturesDetected | The size of detected bathymetric features in an area. | 0..1 | Float 32-bit | See Clause 10.2.8, Note 3 and Clause 10.2.8, Note 4. |
| 6 | featureSizeVar | Percentage of depth that a feature of such size could be detected. | 0..1 | Float 32-bit | Set to zero if the feature size does not scale with depth. See Clause 10.2.8, Note 3 and Clause 10.2.8, Note 4. |
| 7 | fullSeafloorCoverageAchieved | Expression stating if full seafloor coverage has been achieved in the area by hydrographic surveys. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 10.2.8, Note 5. |
| 8 | bathyCoverage | False for grid cells populated by interpolation. | 0..1 | Integer unsigned 8-bit | Boolean, Values: *1 (TRUE) *0 (FALSE). See Clause 10.2.8, Note 6. |
| 9 | zoneOfConfidence.horizontalPositionUncertainty.uncertaintyFixed | The best estimate of the fixed horizontal or vertical accuracy component for positions, depths, heights, vertical distances, and vertical clearances. | 0..1 | Float 32-bit | |
| 10 | zoneOfConfidence.horizontalPositionUncertainty.uncertaintyVariableFactor | The factor to be applied to the variable component of an uncertainty equation so as to provide the best estimate of the variable horizontal or vertical accuracy component for positions, depths, heights, vertical distances, and vertical clearances. | 0..1 | Float 32-bit | |
| 11 | surveyDateRange.dateStart | The start date of the period of the hydrographic survey. | 0..1 | Date | ISO 8602:2004 date format. Complete or truncated date, see S-100, Part 1, Table 2. |
| 12 | surveyDateRange.dateEnd | The end date of the period of the hydrographic survey. | 0..1 | Date | ISO 8602:2004 date format. Complete or truncated date, see S-100, Part 1, Table 2. |
| 13 | sourceSurveyID | The survey filename or ID. | 0..1 | String | |
| 14 | surveyAuthority | The authority which was responsible for the survey. | 0..1 | String | |
| 15 | typeOfBathymetricEstimationUncertainty | The measure used to estimate the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made. | 0..1 | Enumeration | See Table 10-9. See Clause 10.2.8, Note 7. |
NOTE 1 A feature in this context is any object, whether manmade or not, projecting above the sea floor, which may be a danger for surface navigation S-44. Least depth of detected features measured does not describe the least depth of features that were actually detected during a hydrographic survey, but the ability of the survey to detect the least depth of features with a maximum uncertainty as defined in S-44. NOTE 2 A feature in this context is any object, whether manmade or not, projecting above the sea floor, which may be a danger for surface navigation S-44. Significant features detected does not describe if significant features were actually detected during a hydrographic survey, but whether the survey had the capacity to detect significant features. NOTE 3 The role of the attribute, featureSizeVar is described in Clause 7.1. The expectation is that featureSizeVar will be set to zero if the feature size does not scale with depth. As with featureSize, featureSizeVar should be ignored if significantFeatures is False. NOTE 4 When both featureSize and featureSizeVar are present, the greater of the two should be considered valid. NOTE 5 Full seafloor coverage achieved applies to both the spatial completeness of feature detection and to the spatial completeness of the measurement of the regular seafloor. The former is further specified by the complex attribute features detected; the latter by the attributes depth range maximum value and depth range minimum value. NOTE 6 The attribute bathyCoverage is especially useful in side-scan surveys which are characterized by gaps in bathymetric observations with full coverage side-scan imagery. In this case, interpolated gaps between bathymetry coverage would show fullSeafloorCoverageAchieved = True and bathyCoverage = False. However, if fullSeafloorCoverageAchieved = False, bathyCoverage must also equal False (e.g., gaps between single beam echosounder data without correlating side-scan sonar coverage). NOTE 7 Names and listed values which are not currently defined in the IHO GI Registry are subject to change upon acceptance in the Registry. | |||||
Table 10-9 — Codes defining how uncertainty of bathymetric depth was determined
| Role Name | Name | Description | Code | Remarks |
|---|---|---|---|---|
| Enumeration | S102_BatymetricUncertaintyType | An estimate of the magnitude of the difference between true and estimated bathymetric depth, after all appropriate corrections are made. | - | |
| Value | rawStandardDeviation | Raw standard deviations of soundings that contributed to the grid cell. | 1 | - |
| Value | cUBEStandardDeviation | Standard deviation of soundings captured by a CUBE hypothesis (that is, CUBE’s standard output of uncertainty). | 2 | - |
| Value | productUncertainty | The greater of (1) standard deviation of the soundings contributing to the depth solution or, (2) the a priori computed uncertainty estimate (that is, modelled Total Vertical Uncertainty). | 3 | - |
| Value | historicalStandardDeviation | Estimated standard deviation based on historical/archive data. | 4 | - |
| Value | (fill value representing “unknown”) | (fill value when the uncertainty is an unknown layer type) | 0 | This is a “fill value” and will not be in the feature catalogue. |
10.2.9 Instance group QualityOfBathymetryCoverage.01
The QualityOfBathymetryCoverage.01 instance group has the same metadata attributes as BathymetryCoverage.01 instance group (see Table 10-6). The values of the attributes must also be the same as the BathymetryCoverage instance group.
10.2.10 Values group for QualityOfBathymetryCoverage
The values group for QualityOfBathymetryCoverage contains no metadata attributes and a single dataset named values, which is described in Clause 10.2.11.
10.2.11 Values dataset for QualityOfBathymetryCoverage
The values dataset for QualityOfBathymetryCoverage is a single two-dimensional array of unsigned integers (the same datatype and size as the “id” field in featureAttributeTable — Table 10-7). The array must have the same dimensions as the values dataset in the BathymetryCoverage feature instance (Clause 10.2.7).
Each cell in this values dataset must be populated with a value that is one of the record identifiers in the featureAttributeTable dataset or with the fill value 0 (zero).
10.2.12 Mandatory Naming Conventions
The following group and attribute names are mandatory in S-100:
Group_F
featureCode
(for S-102)
BathymetryCoverage
axisNames
BathymetryCoverage.01
QualityOfBathymetryCoverage.01
featureAttributeTable
Group_nnn
11 Data Product Delivery
11.1 Introduction
This clause describes how S-102 data will be delivered from the charting authority to the mariner.
- Units of Delivery
Exchange Set
- Transfer Size
See Clause 11.2.2.
- Medium Name
Digital Data Delivery
- Other Delivery Information
Each dataset must be contained in a physically separate, uniquely identified file on the transfer medium.
Each exchange set has a single exchange catalogue which contains the discovery metadata for each dataset.
An exchange set is encapsulated into a form suitable for transmission by a mapping called an encoding. An encoding translates each of the elements of the exchange set into a logical form suitable for writing to media and for transmission online. An encoding may also define other elements in addition to the exchange set contents (This is media identification, data extents etc. …) and may define commercial constructs such as encryption and compression methods.
If the data is transformed in S-102 it must not be changed.
This Product Specification defines the encoding which must be used as a default for transmission of data between parties.
The encoding encapsulates exchange set elements as follows:
Mandatory Elements
S-102 datasets — HDF encoding
Exchange Catalogue — the XML encoded representation of exchange set catalogue features [discovery metadata].
Optional Elements
S-102 Feature Catalogue — If it is necessary to deliver the latest Feature Catalogue to the end user it may be done using the S-102 exchange set mechanism for datasets
S-102 Portrayal Catalogue — If it is necessary to deliver the latest Portrayal Catalogue to the end user it may be done using the S-102 exchange set mechanism for datasets.
11.2 Dataset
11.2.1 Dataset management
Three types of dataset files may be produced and contained within an exchange set:
New dataset: Initial.
New edition of a dataset: Includes new information. New editions must cover at least the same area as its predecessor.
Cancellation: The dataset is cancelled and no longer available to be displayed or used.
11.2.1.1 Production of a cancellation
S-102 uses only the fileless cancellation method described in S-100, Part 17, Clause 17–4.4.1. In order to cancel a dataset, the cancelling authority (generally the producer of the original dataset) must:
Prepare an exchange catalogue with an S100_DatasetDiscoveryMetadata block with field values as described in Clause 11.2.1.2.
Complete other parts of the exchange catalogue as required by Clause 12.4 (for example, provide discovery metadata for a replacement dataset if such is included in the same exchange set).
Sign and distribute the exchange catalogue in a normally structured exchange set.
11.2.1.2 Metadata for cancellation
S-102 uses only the fileless cancellation method described in S-100, Part 17, Clause 17–4.4.1. For a cancellation, set:
fileName = fileName of the cancelled dataset
purpose = cancellation
issueDate and issueTime = the issue date and time of the cancellation
replacedData = true if and only if the cancelled dataset is replaced by another dataset; otherwise false. This attribute must be populated for a cancellation.
dataReplacement = fileName of the replacement dataset (if and only if the cancelled dataset is replaced by another dataset). This attribute must be populated when replacedData=true.
all other mandatory attributes to the same values as in the discovery metadata block for the dataset being cancelled.
11.2.2 Dataset size
S-102 delivery will take place in one form: network transfer to platform (that is, internet download). An example scenario has been provided below:
NOTE The use of 10 MB in this and other sections should be treated as informative information only. Additionally, any computed values associated with either file size limit should be treated as approximate answers. Final selection of an appropriate file size limit or grid resolution is left to the discretion of the data producer.
- Network Transfer
To minimize overall file size, the HO produces a 10 MB file for wireless transmission to marine vessels. In uncompressed form, this file would contain roughly 600 by 600 grid cells.
Table 11-1 provides general information to aid in the compilation of S-102 data for specific charting scales.
11.2.2.1 S-102 grid resolution and tiling
Table 11-1 — Informative Grid Resolution and Resulting Tile Size at Chart Scale
| Scale | Informative Grid Resolution | Resulting Tile Size @ 10 MB |
|---|---|---|
NULL (only allowed on minimum display scale where the maximum display scale = 10,000,000) | Approximate Linear Distance in Nautical Miles (M) for a 600 X 600 cell grid | |
1:10,000,000 | 900 metres | 291 X 291 |
1:3,500,000 | 900 metres | 291 X 291 |
1:1,500,000 | 450 metres | 145 X 145 |
1:700,000 | 210 metres | 68 X 68 |
1:350,000 | 105 metres | 34 X 34 |
1:180,000 | 54 metres | 17.5 X 17.5 |
1:90,000 | 27 metres | 8.7 X 8.7 |
1:45,000 | 13 metres | 4.2 X 4.2 |
1:22,000 | 6 metres | 1.9 X 1.9 |
1:12,000 | 3 metres | 1.0 X 1.0 |
1:8,000 | 2 metres | 0.6 X 0.6 |
1:4,000 | 1 metres | 0.3 X 0.3 |
1:3,000 | 1 metres | 0.3 X 0.3 |
1:2,000 | 1 metres | 0.3 X 0.3 |
1:1,000 | 1 metres | 0.3 X 0.3 |
11.2.3 Dataset file naming
Dataset naming must follow a standard pattern to give implementers greater predictability of incoming datasets (see S-100, Part 17, Clause 4.3). S-102 dataset naming conventions must follow these rules.
- 102YYYYØØØØØØØØØØØØ.H5
102
the first 3 characters identify the dataset as an S-102 dataset (mandatory).
YYYY
the fourth to seventh characters identify the producer code according to the Producer Code Register.
ØØØØ
the eighth to the maximum nineteenth characters are optional and may be used in any way by the producer to provide the unique file name. The following characters are allowed in the dataset name: A to Z, 0 to 9 and the special character _ (underscore).
H5
denotes an HDF5 file.
11.3 Exchange Set
The structure of an S-102 Exchange Set must be according to the structure described below, which is based on S-100, Part 17, Clause 4.2.
An S-102 Exchange Set must contain an Exchange Set Catalogue, CATALOG.XML, its digital signature CATALOG.SIGN, and may contain any number of S-102 conformant dataset files, support files, and Catalogue files.
All content must be placed inside a top root folder named S100_ROOT. This is the only top level root folder in an Exchange Set containing only S-100 products.
The S100_ROOT folder must contain a subfolder named S-102. This subfolder holds content specific to the S-102 Product Specification.
The S-102 subfolder must contain subfolders for the component dataset files (DATASET_FILES) and Catalogues (CATALOGUES) as required.
The required Exchange Set Catalogue XML document instance must be named CATALOG.XML and placed in the S100_ROOT folder, together with its digital signature (CATALOG.SIGN) file. All other digital signatures are included within their corresponding resource metadata records in the CATALOG.XML.
Support files are not allowed in S-102 exchange sets for this edition of S-102.
11.4 Exchange Catalogue
The Exchange Catalogue acts as the table of contents for the Exchange Set. The Catalogue file of the Exchange Set must be named CATALOG.XML. No other file in the Exchange Set may be named CATALOG.XML. The contents of the Exchange Catalogue are described in Section 12.
11.5 Data integrity and encryption
S-100, Part 15 defines the algorithms for compressing, encrypting and digitally signing datasets based on the S-100 Data Model. The individual Product Specifications provide details about which of the elements are being used and on which files in the dataset.
11.5.1 Use of compression
The data producer decides if compression will be used on the S-102 product files (HDF5). It is expected that a hydrographic office will make a policy decision and that all the S-102 datasets from the producer will be either compressed or uncompressed.
It is recommended to compress all the dataset files, for example HDF5 files. The ZIP compression method defined in S-100, Part 15, Clause 5.2 must be applied to the product files.
11.5.2 Use of data protection
It is recommended to encrypt all the dataset files, for example HDF5. The encryption method defined in S-100, Part 15 must be applied.
11.5.3 Use of digital signatures
Digital signatures shall be used on all files included in a S-102 compliant Exchange Set to meet the requirements of IMO resolution MSC.428(98) to reduce cyber security risks among users, especially when used in navigations systems at sea. The recommended signature method is defined in S-100, Part 15.
The digital signature information is encoded in the corresponding discovery block in the exchange catalogue for each file included in the Exchange Set.
12 Metadata
12.1 Introduction
The Metadata elements used in the Bathymetric Surface product are derived from S-100 and from ISO 19115-1:2014/Amd 1:2018 and ISO 19115-2:2009. Optionally additional metadata may be derived from ISO/TS 19130:2010 and ISO/TS 19130-2:2014 especially metadata relating to the sonar equipment which may have been used to acquire the bathymetric data.
S-102 metadata is encoded in two places:
Metadata used for the discovery, identification, and use of S-102 datasets in S-100-based navigations systems (specifically, an S-100-capable ECDIS) is encoded in the exchange catalogue. This metadata conforms to S-100 Part 17, with product-specific restrictions added.
Metadata required by the S-100 HDF5 encoding (S-100, Part 10c) and product-specific metadata defined by this product specification are encoded at various levels in the HDF5 group hierarchy, as specified by S-100, Part 10c or Clause 10.2.
12.2 Exchange Set metadata
For information exchange, there are several categories of metadata required: metadata about the overall Exchange Catalogue, metadata about each of the datasets contained in the Catalogue.
Figure 12-1 depicts the relationships of exchange set elements (datasets and feature/portrayal catalogues) and exchange set metadata. This figure is derived from S-100, Part 17, Figure 2 with relationships not applicable to S-102 omitted.
Figure 12-2 depicts the structure of the exchange catalogue and its component discovery metadata blocks. The structure is the same as in S-100, Part 17.
More detailed information about the various classes is shown in Figure 12-3 with further description in Table 12-1 to Clause 12.8.2. In the cases in which classes are used without modification, refer to S-100, Part 17 for their descriptions.
The discovery metadata classes have numerous attributes which enable important information about the datasets to be examined without the need to process the data (e.g., decryption, decompression, loading). Other Catalogues can be included in the Exchange Set in support of the datasets such as Feature and Portrayal.
Figure 12-1 — Components and associated metadata for the S-102 exchange set (S-100, Part 17, Figure 2 with items not used by S-102 omitted)
Figure 12-2 — Relationship between exchange catalogue, discovery metadata, and dataset (S-100, Part 17, Figure 6 with items not used by S-102 omitted)
Figure 12-3 — S-102 Exchange Set Class Details (S-100, Part 17, Figure 7 with items not used by S-102 omitted)
The following clauses define the mandatory and optional metadata needed for S-102. In some cases, the metadata may be repeated in a national language. If this is the case it is noted in the Remarks column.
The XML schemas for S-102 exchange catalogues will be available from the IHO Geospatial Information (GI) Registry and/or the S-100 GitHub site (https://github.com/IHO-S100WG).
The S-102 exchange catalogue uses the S-100 exchange catalogue schemas which are available from the S-100 schema server at https://schemas.s100dev.net (downloadable archives are also available on the site for offline use). Implementation of the S-102-specific constraints described in following clauses below is left to developer decision as it can be done in various ways depending on implementation frameworks and the requirements of production or application software.
12.3 Language
The exchange language must be English.
Character strings must be encoded using the character set defined in ISO/IEC 10646-1:2000, in Unicode Transformation Format-8 (UTF-8). A BOM (byte order mark) must not be used.
12.4 S100_ExchangeCatalogue
Each Exchange Set has a single S100_ExchangeCatalogue which contains meta information for the data in the Exchange Set.
S-102 uses S100_ExchangeCatalogue without modification.
12.4.1 S100_ExchangeCatalogueIdentifier
S-102 uses S100_ExchangeCatalogueIdentifier without modification.
12.4.2 S100_CataloguePointOfContact
S-102 uses S100_CataloguePointOfContact without modification.
12.5 S100_DatasetDiscoveryMetadata
Dataset discovery metadata in S-102 restricts certain attributes and roles as described in Table 12-1. Optional S-100 attributes which are mandatory in S-102 are indicated in the Remarks column.
Table 12-1 — S100_DatasetDiscoveryMetadata parameters
| Role name | Name | Description | Mult | Type | Remarks |
|---|---|---|---|---|---|
Class | S100_DatasetDiscoveryMetadata | Metadata about the individual datasets in the Exchange Catalogue | - | - | The optional S-100 attributes updateNumber, updateApplicationDate, referenceID, and temporalExtent are not used in S-102. |
Attribute | fileName | Dataset file name | 1 | URI | See S-100, Part 1, Clause 4.6 |
Attribute | description | Short description giving the area or location covered by the dataset | 0..1 | CharacterString | For example a harbour or port name, between two named locations, etc. |
Attribute | datasetID | Dataset ID expressed as a Maritime Resource Name | 0..1 | URN | The URN must be an MRN. |
Attribute | compressionFlag | Indicates if the resource is compressed | 1 | Boolean | True indicates a compressed dataset resource. |
Attribute | dataProtection | Indicates if the data is encrypted | 1 | Boolean | True indicates an encrypted dataset resource. |
Attribute | protectionScheme | Specification of method used for data protection | 0..1 | S100_ProtectionScheme | Populate if and only if dataProtection = True. |
Attribute | digitalSignatureReference | Specifies the algorithm used to compute digitalSignatureValue | 1 | S100_SE_DigitalSignatureReference | See clause8.11.7 & Clause 12.9 |
Attribute | digitalSignatureValue | Value derived from the digital signature | 1..* | S100_SE_DigitalSignature | see S-100, Part 15, Clause 15–8.11.3 |
Attribute | copyright | Indicates if the dataset is copyrighted | 1 | Boolean | True indicates the resource is copyrighted. |
Attribute | classification | Indicates the security classification of the dataset | 1 | Class | Mandatory in S-102
|
Attribute | purpose | The purpose for which the dataset has been issued | 1 | S100_Purpose | Mandatory in S-102 |
Attribute | notForNavigation | Indicates the dataset is not intended to be used for navigation | 1 | Boolean | True indicates the dataset is not intended to be used for navigation. |
Attribute | specificUsage | The use for which the dataset is intended | 0..1 | MD_USAGE>specificUsage (character string) | - |
Attribute | editionNumber | The edition number of the dataset | 1 | Integer | When a data set is initially created, the Edition number 1 is assigned to it. The Edition number is increased by 1 at each new Edition. Edition number remains the same for a re-issue. |
Attribute | issueDate | Date on which the data was made available by the Data Producer | 1 | Date | - |
Attribute | issueTime | Time of day at which the data was made available by the Data Producer | 0..1 | Time | The S-100 datatype Time |
Attribute | boundingBox | The extent of the dataset limits | 1 | EX_GeographicBoundingBox | Mandatory in S-102 |
Attribute | productSpecification | The Product Specification used to create this dataset | 1 | S100_ProductSpecification | |
Attribute | producingAgency | Agency responsible for producing the data | 1 | CI_Responsibility>CI_Organisation | |
Attribute | producerCode | The official IHO Producer Code from S-62 | 1 | CharacterString | Mandatory in S-102 |
Attribute | encodingFormat | The encoding format of the dataset | 1 | S100_EncodingFormat | The only allowed value is HDF5 |
Attribute | dataCoverage | Provides information about data coverages within the dataset | 1..* | S100_DataCoverage | Mandatory in S-102 |
Attribute | comment | Any additional information | 0..1 | CharacterString | - |
Attribute | defaultLocale | Default language and character set used in the dataset | 0..1 | PT_Locale | In absence of defaultLocale, the language is English, and the character set is UTF-8. |
Attribute | otherLocale | Other languages and character sets used in the dataset | 0..* | PT_Locale | |
Attribute | metadataPointOfContact | Point of contact for metadata | 0..1 | CI_Responsibility>CI_Individual | Only if metadataPointOfContact differs from producingAgency |
Attribute | metadataDateStamp | Date stamp for metadata | 0..1 | Date | May or may not be the issue date |
Attribute | replacedData | Indicates if a cancelled dataset is replaced by another data file(s) | 0..1 | Boolean | See note following S-100, Part 17, Table S100_DatasetDiscoveryMetadata |
Attribute | dataReplacement | Dataset name | 0..* | CharacterString | A dataset may be replaced by 1 or more datasets. |
Attribute | navigationPurpose | Classification of intended navigation purpose (for Catalogue indexing purposes) | 1..3 | S100_NavigationPurpose | If Product Specification is intended for creation of navigational products, this attribute should be mandatory. |
Role | resourceMaintenance | Information about the frequency of resource updates, and the scope of those updates | 0..1 | MD_MaintenanceInformation | S-100 restricts the multiplicity to 0..1 and adds specific restrictions on the ISO 19115 structure and content. See S-100, Part 17. |
12.5.2 S100_DataCoverage
S-102 uses S100_DataCoverage without modification, but with additional remarks and changes to the multiplicity.
Table 12-2 — S100_DataCoverage parameters
| Role name | Name | Description | Mult | Type | Remarks |
|---|---|---|---|---|---|
Class | S100_DataCoverage | A spatial extent where data is provided along with the display scale information for the provided data | - | - | This field is used by user systems as part of the data loading and unloading algorithms, and it is strongly encouraged that Product Specifications mandate the use of one or more of the displayScale provided as part of S100_DataCoverage. |
Attribute | boundingPolygon | A polygon which defines the actual data limit | 1 | EX_BoundingPolygon | |
Attribute | temporalExtent | Specification of the temporal extent of the coverage | 0 | S100_TemporalExtent | The temporalExtent is not used in S-102. |
Attribute | optimumDisplayScale | The scale at which the data is optimally displayed | 0..1 | Integer | Example: A scale of 1:25000 is encoded as 25000 |
Attribute | maximumDisplayScale | The maximum scale at which the data is displayed | 0..1 | Integer | |
Attribute | minimumDisplayScale | The minimum scale at which the data is displayed | 0..1 | Integer | |
Attribute | approximateGridResolution | The resolution of gridded or georeferenced data (in metres) | 1..2 | Real | Mandatory in S-102 |
NOTE boundingPolygon is restricted to a single GML Polygon with one exterior and 0 or more interiors expressed as Linear Rings using SRS EPSG:4326. The exterior and optional interiors shall be composed of a closed sequence of >=4 coordinate positions expressed individually or as a list (posList). The GML polygon shall have a valid GML identifier. | |||||
12.5.3 S100_Purpose
S-102 uses S100_Purpose without modification, but with a restriction on the allowed values.
Table 12-3 — S100_Purpose
| Role name | Name | Description | Code | Remarks |
|---|---|---|---|---|
Enumeration | S100_Purpose | The purpose of the dataset | - | The S-100 values update, reissue, and delta are not used in S-102. |
Value | newDataset | Brand new dataset | 1 | No data has previously been produced for this area. |
Value | newEdition | New edition of the dataset or Catalogue | 2 | Includes new information which has not been previously distributed by updates. |
Value | cancellation | Dataset or Catalogue that has been cancelled | 5 | Indicates the dataset or Catalogue should no longer be used and can be deleted. |
12.5.4 S100_EncodingFormat
S-102 uses S100_EncodingFormat with a restriction on the allowed values to permit only the S-100 HDF5 format for S-102 datasets.
Table 12-4 — S100_EncodingFormat parameters
| Role name | Name | Description | Code | Remarks |
|---|---|---|---|---|
Enumeration | S100_EncodingFormat | The encoding format | - | The only value allowed in S-102 is “HDF5”. |
Value | HDF5 | The HDF5 data format as defined in S-100, Part 10c | 3 | - |
12.5.5 S100_ProductSpecification
S-102 uses S100_ProductSpecification without modification, but with additional remarks and changes to the multiplicity.
Table 12-5 — S100_ProductSpecification parameters
| Role name | Name | Description | Mult | Type | Remarks |
|---|---|---|---|---|---|
Class | S100_ProductSpecification | The Product Specification contains the information needed to build the specified product. | - | - | - |
Attribute | name | The name of the Product Specification used to create the datasets | 1 | CharacterString | The name in the GI Registry should be used for this field. |
Attribute | version | The version number of the Product Specification | 1 | CharacterString | TR 2/2007 specifies versioning of Product Specifications |
Attribute | date | The version date of the Product Specification | 1 | Date | - |
Attribute | productIdentifier | Machine readable unique identifier of a product type | 1 | CharacterString | For S-102, this identifier is “S-102” (without quotes). |
Attribute | number | The number used to lookup the product in the Product Specification Register of the IHO GI registry | 1 | Integer | For IHO Product Specifications, these numbers should be taken from the IHO Product Specification Register in the IHO GI Registry. |
Attribute | compliancyCategory | The level of compliance of the Product Specification to S-100 | 0..1 | S100_CompliancyCategory | See S-100, Part 4a, Clause 4a–5.5 and Clause 12.5.6 below. |
12.5.6 S100_CompliancyCategory
S-102 exchange sets conforming to this edition of S-102 and using a CRS from the EPSG registry may be encoded as category 3 or 4 when the compliancyCategory metadata attribute is populated. Because S-98 interoperability assumes category4 datasets, category4 may be used for test purposes, though the absence of test datasets and of a published IHO interoperability catalogue mean this edition of S-102 does not yet qualify for category4. Given the uncertainty about interoperability testing requirements and availability of test datasets, the S-100 WG chair and S-102 PT chair should be consulted for up-to-date guidance.
Table 12-6 — S100_CompliancyCategory
| Role Name | Name | Description | Code | Remarks |
|---|---|---|---|---|
Enumeration | S100_CompliancyCategory | - | - | S-102 should use category3 or category4, subject to the guidance provided in Clause 12.5.6. |
Value | category3 | IHO S-100 compliant with standard encoding | 3 | Qualifies as category2; plus “The Product Specification uses only an encoding method defined in S-100, Part 10 and Part 4a, Clause 5.5.3” |
Value | category4 | IHO S-100 and IMO harmonized display compliant | 4 | Qualifies as category3; plus additional requirements, including a portrayal catalogue, cybersecurity (digital signatures and encryption), test material, use of a CRS from the EPSG Registry, and compliance with the IHO S-98 interoperability catalogue. S-100, Part 4a, Clause 5.5.4 |
12.5.7 S100_ProtectionScheme
S-102 uses S100_ProtectionScheme without modification.
12.6 MD_MaintenanceInformation
S-102 uses MD_MaintenanceInformation without modification.
12.7 MD_MaintenanceFrequencyCode
S-102 uses MD_MaintenanceFrequencyCode without modification.
12.8 S100_CatalogueDiscoveryMetadata
S-102 uses S100_CatalogueDiscoveryMetadata without modification.
12.8.1 S100_CatalogueScope
S-102 uses S100_CatalogueScope without modification.
12.8.2 PT_Locale
S-102 uses PT_Locale without modification. The class PT_Locale is defined in ISO 19115-1:2014/Amd 1:2018. LanguageCode, CountryCode, and MD_CharacterSetCode are ISO codelists which are defined in a codelists file which is part of the S-100 Edition 5.2.0 schema distribution.
12.9 Certificates and Digital Signatures
The classes S100_SE_CertificateContainerType (S-100, Part 15, Clause 8.11.1), S100_SE_DigitalSignatureReference (S-100, Part 15, Clause 8.11.7), and S100_SE_DigitalSignature are defined in S-100, Part 15 and implemented in the S-100 generic schemas.
In accordance with S-100, Part 15, only the ECDSA algorithm is allowed from the S100_SE_DigitalSignatureReference enumeration.
S-102 uses S100_SE_DigitalSignature without modification. As stated in S-100, Part 15, Clause 15–8.11.3:
“The class S100_SE_DigitalSignature is realized as one of either S100_SE_SignatureOnData (a digital signature of a particular identified resource) or an additional digital signature defined using the class S100_SE_AdditionalSignature, each of which is either a S100_SE_SignatureOnData or S100_SE_SignatureOnSignature element as described in S-100, Part 15, Clause 8.8. S-100, Part 17 metadata thus allows for multiple digital signatures, a single mandatory S100_SE_SignatureOnData and any number of additional signatures, either of the data or other signatures.”
Annex A
Data Classification and Encoding Guide
A.1 Features
A.1.1 BathymetryCoverage
Table A-1 — BathymetryCoverage feature parameters
Term: Bathymetry Coverage | |||
IHO Definition: A set of value items required to define a dataset representing a depth calculation and its associated uncertainty. | |||
Primitive: S100_IF_GridCoverage | |||
| Attribute | Allowable Encoding Value | Type | Multiplicity |
|---|---|---|---|
depth | Must be in decimal metres with resolution not to exceed 0.01 metres | real (32-bit Float) | 1 |
uncertainty | Must be in decimal metres with resolution not to exceed 0.01 metres | real (32-bit Float) | 0..1 |
A.1.2 QualityOfBathymetryCoverage
Table A-2 — QualityOfBathymetryCoverage feature parameters
Term: Quality Of Bathymetry Coverage. | |||
IHO Definition: A set of references to value records that provide localised information about depth, uncertainties, and bathymetry coverage metadata. | |||
Primitive: S100_IF_GridCoverage | |||
| Attribute | Constraint | Type | Multiplicity |
|---|---|---|---|
iD | Each record must have a unique identifier. | unsigned 32-bit Integer | 1 |
A.2 Feature Attributes
A.2.1 BathymetryCoverage
Table A-3 — BathymetryCoverage feature attribute parameters
IHO Definition: depth. The vertical distance from a given water level to the bottom [S-32]. |
Unit: metres |
Resolution: 0.01 |
Remarks:
|
IHO Definition: uncertainty. Estimate characterising the range of values within which the true value of a measurement is expected to lie as defined within a particular confidence level. It is expressed as a positive value. |
Unit: metres |
Resolution: 0.01 |
Remarks:
|
A.2.2 QualityOfBathymetryCoverage
Table A-4 — QualityOfBathymetryCoverage feature attribute parameters
IHO Definition: iD. Meta data record identifier for QualityOfBathymetryCoverage |
Unit: |
Resolution: |
Remarks: |